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ABSTRACT 

Traditionally, the design and implementation of a 
conventional database system begins with the selection o f a 
data model, followed by the specification of a model-based 
data language. An alternative to this traditional approach 
to database system development is the mul ti — 1 i ngual database 
system (MLDS), This alternative approach affords the user 
the ability to access and manage a large collection of 
databases via several data models and their correspond! ng 
data languages. 

In this thesis we present the speci f i cat i on and 
implementation of a hi er archi cal /DL/ I language interface for 
the MLDS. Specifically, we present the speci f i cati on and 
implementation of an interface which translates DL/I data 
language calls into attribute-based data language (ABDL) 
requests. We describe the software engineering aspects of 
our implementation and an overview of the four modules which 
comprise our DL/I language interface. 
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I. INTRODUCTION 



A. MOTIVATION 

During the past twenty years database systems have 
been designed and implemented using what we refer to as the 
traditional approach. The first step in the traditional 
approach involves choosing a data model. Candidate data 
models include the hierarchical data model, the relational 
data model, the network data model, the ent i ty— rel at i onshi p 
data model , or the attr i bute-based data model to name a few. 
The second step specifies a model— based data language, e.g., 
DL/I for the hierarchical data model, or Daplex for the 
ent i ty— rel ati onshi p data model. 

A number of database systems have been developed using 
this methodology. For example, IBM has introduced the 
Information Management System (IMS) in the sixties, which 
supports the hierarchical data model and the hierarchical- 
model— based data language, Data Language I (DL/I). Sperry 
Uni vac has introduced the DMS— 1100 in the early seventies, 
which supports the network data model and the network- 
model-based data language, CODASYL Data Manipulation 
Language (CODASYL-DML) . And more recently, there has been 
IBM's introduction of the SQL/Data System which supports the 
relational model and the rel at i onal —model —based data 
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language, Structured English Query Language (SQL) , The 
result of this traditional approach to database system 
development is a homogeneous database system that restricts 
the user to a single data model and a specific model— based 
data language. 

An unconventional approach to database system 
development, referred to as the dyi£^-^ingual_ Dat abase 
System (MLDS) CRef. 13, alleviates the af or ement i oned 
restriction- This new system affords the user the ability 
to access and manage a large collection of databases via 
several data models and their corresponding data languages. 
The design goals of the MLDS involve developing a system 
that is accessible via a hierarchical /DL/I interface, a 
relational /SQL interface, a net wor k/CODASYL interface, and 
an enti ty-rel ati onshi p/Dapl ex i nterface. 

There are a number of advantages in developing such a 
system- Perhaps the most practical of these involves the 
reusability of database transactions developed on an 
existing database system- In the MLDS, there is no need for 
the user to convert a transaction from one data language to 
another- The MLDS permits the running of database 
transactions written in different data languages. 
Therefore, the user does not have to perform either manual 
or automated translation of existing transactions in order 
to execute a transaction in the MLDS- The MLDS provides the 
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same results even it the data language of the transaction 
originates at a different database system. 

A second advantage deals with the economy and 
effectiveness of hardware upgrade. Frequently, the hardware 
supporting the database system is upgraded because of 
technological advancements or system demand- With the 
traditional approach, this type of hardware upgrade has to 
be provided for all of the different database systems in 
use, so that all of the users may experience system 
performance improvements. This is not the case in the MLDS, 
where only the upgrade of a single system is necessary. In 
the MLDS, the benefits of a hardware upgrade are uniformly 
distributed across all users, despite their use of different 
models and data languages. 

Thirdly, a multi— 1 ingual database system allows users to 
explore the desirable features of the different data models 
and then use these to better support their applications. 
This is possible because the MLDS supports a variety of 
databases structured in any of the well-known data models. 

It is apparent that there exists ample motivation to 
develop a mul ti — 1 i ngual database system with many data 
model /data language interfaces. In this thesis, we are 
developing a h i erarch i cal /DL/ I language interface for the 
MLDS. We are extending the work of Banerjee CRef. 23 and 
Weishar CRef. 33, who have shown the feasibility of this 
particular interface in a MLDS. 
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B. THE MULT I -LINGUAL DATABASE SYSTEM 



A detailed discussion o-f each o-f the components o-f the 
MLDS is provided in subsequent chapters- In this section we 
provide an overview o-f the organization o-f the MLDS- This 
assists the reader in understanding how the di-f-ferent 
components o-f the MLDS are related. 

Figure 1 shows the system structure o-f a mul t i — 1 i ngual 
database system- The user interacts with the system through 
the language Interface layer (LTL) , using a chosen user data 
!B 9 del To issue transactions written in a correspond i ng 
model— based user data language (UDL) - The LIL routes the 
user transactions to the kernel magging system (KMS) - The 
KMS performs one o-f two possible tasks- First, the KMS 
trans-forms a UDM— based database de-finition to a database 
de-finition o-f the kernel data model <KDM> , when the user 
speci-fies that a new database is to be created- When the 
user speci-fies that a UDL transaction is to be executed, the 
KMS translates the UDL transaction to a transaction in the 
kernel data language (KDL) . In the -first task, the KMS 
-forwards the KDM data de-finition to the kernel controller 
<KC> . The KC, in turn, sends the KDM database definition to 
the kernel database system (KDS). When the KDS is -finished 
with processing the KDM database de-finition, it in-forms the 
KC- The KC then noti-fies the user, via the LIL, that the 
database de-finition has been processed and that loading o-f 
the database records may begin- In the second task, the KMS 
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UDM 


: User Data Model 


UDL 


: User Data Language 


LIL 


: Language Interface Layer 


KMS 


: Kernel Mapping System 


KC 


: Kernel Controller 


KFS 


: Kernel Formatting System 


KDM 


: Kernel Data Model 


KDL 


: Kernel Data Language 


KDS 


: Kernel Database System 



Figure 1- The Mul t i -Li ngual Database System, 
sends the KDL transactions to the KC. When the KC receives 
the KDL transactions, it forwards them to the KDS for 
execution. Upon completion, the KDS sends the results in 
KDM form back to the KC. The KC routes the results to the 
ker nel_ formatting system ( KFS ) . The KFS ref ormats the 
results from KDM form to UDM form. The KFS then displays 
the results in the correct UDM form via the LIL. 

The four modules, LIL, KMS , KC , and KFS, are 

collectively known as the language interface. Four similar 



nodules are required tor each other language interface of 
the MLDS. For example, there are four sets of these modules 
where one set is for the hierarchical /DL/I language 
interface, one for the r el at 1 onal /SQL language interface, 
one for the net wor k/CQDASYL language interface, and one for 
the enti ty-relationship/Daplex language interface. However, 
if the user writes the transaction in the native mode ti.e. , 
in KDL) , there is no need for an interface. 

In our implementation of the hierarchical/DL/I language 
interface, we develop the code for the four modules. 
However, we do not integrate these modules with the KDS as 
shown in Figure 1. The Laboratory of Database Systems 
Research at the Naval Postgraduate School is in the process 
of procuring new computer equipment for the KDS. When the 
equipment is installed, the KDS is to be ported over to the 
new equipment. The MLDS software is then to be integrated 
with the KDS. Although not a very difficult undertaking, it 
may be time-consuming. 

C. THE KERNEL DATA MODEL AND LANGUAGE 

The choice of a kernel data model and a kernel data 
language is the key decision in the development of a multi- 
lingual database system. The overriding question, when 
making such a choice, is whether the kernel data model and 
kernel data language is capable of supporting the required 
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data-model transformations and data-1 anguage translations 
tor the language interfaces. 

The attr i bute-based data model proposed by Hsiao 
CRef. 43, extended by Wong CRef. 53, and studied by Rothnie 
CRef. 63, along with the attr ibute-based data language 
(ABDL) , defined by Banerjee CRef. 73, have been shown to be 
acceptable candidates for the kernel data model and kernel 
data language, respectively. 

Why is the determi nat i on of a kernel data model and 
kernel data language so important for a MLDS? No matter how 
mul t i -1 i ngual the MLDS may be, if the underlying database 
system (i.e., KDS> is slow and inefficient, then the 
interfaces may be rendered useless and untimely. Hence, it 
is important that the kernel data model and kernel language 
be supported by a high-performance and great— capaci ty 
database system. Currently, only the attribute-based data 
model and the attr ibute-based data language are supported by 
such a system. This system is the mul ti -backend database 
system (MBDB) CRef. 13. 

D. THE MULTI-BACKEND DATABASE SYSTEM 

The mul ti -backend database system (MBDS) has been 
designed to overcome the performance problems and upgrade 
issues related to the traditional approach of database 
system design. This goal is realized through the 
utilization of multiple backends connected in a parallel 
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Backend Store 1 






Figure 2. The Mul ti -Backend Database System. 

-fashion. These backends have identical hardware, replicated 
software, and their own disk systems. In a multiple 
backend-configuration, there is a backend controller, which 
is responsible for supervising the execution of database 
transactions and for interfacing with the hosts and users. 
The backends perform the database operations with the 
database stored on the disk system of the backends. The 
controller and backends are connected by a communication 



17 



bus. Users access the system through either the hosts or 
the controller directly (see Figure 2). 

Per-Formance gains are realized by increasing the number 
of backends. It the size of the database and the size of 
the responses to the transactions remain constant , then MBDS 
produces a reciprocal decrease in the response times tor the 
user transactions when the number ot backends is increased. 
On the other hand, it the number ot backends is increased 
proport i onal 1 y with the increase in databases and responses, 
then MBDS produces invariant response times tor the same 
transactions. A more detailed discussion ot MBDS is tound 
in [Ret. 83. 

E. THESIS OVERVIEW 

The organization ot our thesis is as follows: In 
Chapter II, we discuss the sottw are engineering aspects ot 
our implementation. This includes a discussion ot our 
design approach , as well as a review ot the global data 
structures used tor the implementation. In Chapter III, we 
outline the tuncti onal i ty ot the language interface layer. 
In Chapter IV, we articulate the processes constituting the 
kernel mapping system. In Chapter V, we provide an overview 
ot the kernel controller. In Chapter VI, we describe the 
kernel formatting system. In Chapter VII, we conclude the 
thesis. 
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Appendix A covers the data structure diagrams tor the 
shared and local data. The detailed specifications of the 
interface modules <i.e. , LIL, KMS , KC, and KFS) are given in 
Appendices B, C, D, and E, respectively. Appendix F is a 
users' manual for the system. The specifications of the 
source data language, DL/I, and the target data language, 
ABDL, is found in CRef. 17: pp. 282-3071 and CRef. 73, 
respect i vel y . 

Throughout this thesis, we provide examples of DL/I 
requests and their translated ABDL equivalents. All 
examples involving database operations presented in this 
thesis are based on the education database described in Date 
CRef. 17: pp. 279-2843, and shown in Figure 3. 
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II. 



SOFTWARE ENGINEERING OF A LANGLJAGE INTERFACE 



In this chapter, we discuss the various software 
engineering aspects of developing a language interface. 
First, we describe our design goals. Second, we outline the 
design approach that we have taken to implement the 
inter-face. Included in this section are discussions of our 
implementation strategy, our software development 
techniques, and salient char acter i st i cs of the language 
interface software. Then, we provide a critique of our 
implementation. Fourth, we describe the data structures 
used in the interface. And finally, we provide an 
organizational description of the next four chapters. 

A. DESIGN GOALS 

We are motivated to implement a DL/I interface for a 
MLDS using MBDS as the kernel database system, the 
attribute-based data model as the kernel data model , and 
ABDL as the kernel data language. It is important to note 
that we do not propose changes to the kernel database system 
or language. Instead, our implementation resides entirely 
in the host computer. All user transactions in DL/I are 
processed in the DL/I interface. MBDS continues to receive 
and process requests in the syntax and semantics of ABDL. 
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In addition, we intend to make our inter-face transparent 
to the user. For example, an employee in a corporate 
environment with previous experience with DL/I could log 
into our system, issue a DL/I request and receive resultant 
data in a hierarchical -format, i.e., a segment. The 
employee requires no training in ABDL or MBDS procedures 
prior to utilizing the system. 

B. „ AN APPROACH TO THE DESIGN 

1 . The Implementation Strategy 

There are a number o-f di-f-ferent strategies we might 
have employed in the implementation o-f the DL/I language 
inter-face. For example, there are the bui 1 d— i t— twi ce -full- 
prototype approach, the 1 evel -by-1 evel top-down approach, 
the incremental development approach , and the advancemanshi p 
approach ERef. 10: pp. 41—461. We have predicated our 
choice on minimizing the "so-ftware-crisis" as described by 
Boehm ERef. 10: pp. 14-311. 

The strategy we have decided upon is the level -by- 
level top-down approach. Our choice is based on, -first, a 
time constraint. The inter-face has to be developed within a 
speci-fied time, specifically, by the time we graduate. And 
second, this approach lends itsel-f to the natural evolution 
o-f the interface. The system is initially thought of as a 
"black box 11 (see Figure 1) that accepts DL/I transactions 
and then returns the appropriate results. The "black box 11 



21 



